Thanks so much! I haven't had the chance to test yet, but this looks very close.

Due to #111 , unfortunately, this needs to be updated in two places at the moment -- both prepare.php and functions.php.

I need to resurrect that issue / patch / diff at some point (or help is welcome) to refactor and turn it into an optional SSH call for gathering environment data, but I think it's fine to go ahead and add this in the meantime.

Due to #111 , unfortunately, this needs to be updated in two places at the moment -- both prepare.php and functions.php.

I missed that, will add there as well. Thanks for the tip.

Addressed feedback:

• Added to functions.php.
• Lower case naming.

@getsource friendly ping, this should be ready to go!

Thanks! Trying to test, but ran into some environment difficulties with app passwords and the reporter plugin.
Will ping back when I've been able to test.

Here are relevant locations for the reporter, for consideration of the unavailable values:
https://github.com/WordPress/phpunit-test-reporter/blob/master/parts/single-result.php#L50
https://github.com/WordPress/phpunit-test-reporter/blob/master/src/class-display.php#L337

I created an issue to add the data if available to the reports: WordPress/phpunit-test-reporter#97

When successful, an array gets inserted for both items. Would an empty array (or not including it at all / "empty") make it easier to parse this in the reporter when "unavailable"?

Good point, I hadn't considered the reporting end of things. Makes more sense for the default value to be an empty array vs. the string 'unavailable'. I will update the PR.

@getsource - I changed the defaults to empty array as per your suggestion. This should be good to merge.

@pfefferle @getsource What are the next steps to get this merged (plus WordPress/phpunit-test-reporter#98).

Also: once this is merged, how is deployed in the wild, when could we hope to start seeing data reported?

My suggested steps would be:

• Review of this PR's code
• Review of the other PR's code
• Testing both of the two together (WP.org meta environment for the latter).
• Merge of both PRs
• Create New Plugin Version for the reporter
• Create meta patch for the reporter PR (using the reporter build tools)
• Make meta ticket, with that patch attached
• Commit from the meta team to make the new version of the reporter live

I don't think this PR necessarily needs to wait for the latter, but having them work together as a proof of concept definitely would help verify/validate.

I don't recall whether sending the data to the reporter when it isn't expecting it (if this PR is merged first) would cause validation issues with the API or not, but looking+testing to make sure it works as expected would be good before this is merged.

As far as when data is received: After the above is done, because updating the runner code is dependent on the client, I suspect some hosts will start to report right away (if they clone this repo as part of the testing process), and for others it will take an undefined amount of time until they decide to manually update.

I don't have the time at the moment to work on this, unfortunately, so help is appreciated.

Just cross referencing the recent Core changeset that added this data to update pings to .org: https://core.trac.wordpress.org/changeset/53753.